El 18 de septiembre de 2026, el equipo de DuckDB publicó un artículo técnico explicando cómo su motor analítico compilado a WebAssembly puede abrir ahora una base de datos persistente directamente en el disco del usuario, sin servidor de por medio, apoyándose en el Origin Private File System del navegador. Una semana antes, FOSDEM 2026 había dedicado por primera vez una vía completa a «local-first, sync engines y CRDTs», bajo el lema «tus datos son tuyos, a pesar de la nube». Y según las últimas encuestas del sector, más del 70% de los desarrolladores ya usa o evalúa WebAssembly fuera del navegador clásico, con dos tercios de los proyectos empresariales nuevos incorporando al menos un módulo WASM.
Ninguno de estos tres hechos es una anécdota aislada. Son la misma tendencia vista desde tres ángulos distintos: el navegador ha dejado de ser un visor de documentos y se ha convertido en un runtime con sistema de archivos, base de datos local, ejecución casi nativa de binarios y un proxy de red programable integrado. La mayoría del código que se sigue escribiendo, sin embargo, trata al navegador como si solo fuera una ventana hacia el servidor. Ese desfase es exactamente donde se acumula backend que ya no hace falta.
WebAssembly: ejecutar lo que nunca se pensó para el navegador
Cuando se habla de WebAssembly, la asociación automática sigue siendo rendimiento: juegos, motores 3D, simulaciones físicas. Pero la idea de fondo es otra: WASM permite ejecutar en el navegador binarios compilados de código que nunca se escribió pensando en la web.
FFmpeg es un proyecto en C de más de veinte años que nadie diseñó para correr en una pestaña de Chrome; compilado a WebAssembly, procesa vídeo entero en el cliente. SQLite corre en el navegador desde hace tiempo vía sql.js y, más recientemente, wa-sqlite. Y el caso de DuckDB-Wasm mencionado arriba va un paso más allá: no solo ejecuta consultas SQL analíticas sobre datos en memoria, sino que persiste la base de datos completa en un archivo `opfs://` que sobrevive a recargas y reinicios del navegador, usando los sync access handles de OPFS (solo disponibles dentro de un Web Worker, una restricción técnica que conviene tener en cuenta al diseñarlo).
En el plano de las especificaciones, 2026 ha sido el año en que WASI ha madurado de verdad. WASI 0.3, publicado en febrero, añadió soporte nativo para operaciones asíncronas mediante futures y streams del Component Model: JavaScript convierte esos futures en promesas de forma transparente, Rust los espera como funciones async normales, y cada lenguaje lo integra con su propio modelo de concurrencia sin código de pegamento manual. El Component Model que empaqueta módulos WASM con interfaces tipadas y componibles ha resuelto buena parte del problema de interoperabilidad que hacía cara la mezcla de lenguajes dentro de un mismo proyecto. WASI 1.0, la versión estable pensada para despliegues en producción, está prevista para este mismo año.
El ejemplo que mejor resume hasta dónde llega esto en producción es StackBlitz WebContainers: un runtime completo de Node.js con `npm install`, servidor de desarrollo y sistema de archivos incluidos ejecutándose dentro de la pestaña vía WebAssembly, arrancando en un par de segundos y funcionando aunque se pierda la conexión. Es la infraestructura detrás de StackBlitz y de editores online similares, y es la prueba de que «Node en el navegador» ya no es un experimento de conferencia.
WebGPU: cómputo en GPU, no solo en CPU
WebAssembly resuelve el cómputo en CPU, pero desde 2023 hay una pieza paralela que muchos backends siguen ignorando: WebGPU da acceso directo a la GPU del usuario desde JavaScript, con soporte estable en Chrome desde la versión 113 en escritorio y desde la 121 en Android 12 o superior (conviene verificar el driver concreto de cada dispositivo, la cobertura no es uniforme). Se usa ya para inferencia de modelos de IA pequeños directamente en el cliente, procesamiento de imagen y vídeo acelerado por hardware, y renderizado que antes exigía WebGL con mucho más código de por medio. Sumado a WASM, el navegador cubre hoy tanto cómputo general como cómputo paralelo masivo, las dos piezas que hasta hace poco justificaban mandar cualquier tarea pesada a un servidor con GPU.
Aplicaciones enteras viven dentro de una pestaña
La lista de software que hace una década se daba por hecho que necesitaba instalación y hoy corre entero en el navegador no deja de crecer:
- Figma procesa localmente archivos de diseño enormes, capas y vectores en tiempo real, con un motor de renderizado propio compilado a WASM.
- VS Code Web y GitHub Codespaces meten explorador de archivos, terminal, extensiones y control de Git dentro del navegador; lo que antes exigía instalar un IDE completo ahora se abre con una URL.
- Photoshop en la web, que Adobe lleva puliendo varios años, ha ido erosionando uno de los argumentos más sólidos a favor del software de escritorio: la edición de imagen pesada con capas.
- StackBlitz y editores construidos sobre WebContainers ofrecen entornos fullstack completos backend, frontend y base de datos incluidos sin ninguna máquina remota detrás.
Para equipos que siguen diseñando arquitecturas con el reflejo de mandar cualquier cálculo pesado a un servidor, la pregunta que cada vez tiene más sentido hacerse en la fase de diseño es simplemente si esa pieza concreta necesita salir del navegador.
File System Access API: leer y escribir archivos reales
Antes de esta API, si una aplicación web necesitaba tocar un archivo, el flujo era: el usuario lo sube, el servidor lo procesa, el servidor devuelve el resultado, el usuario lo descarga. Incluso cuando el servidor no hacía nada complejo, el archivo daba un viaje de ida y vuelta por la red.
La File System Access API permite que el usuario conceda permiso al navegador para leer y escribir directamente sobre archivos reales de su disco, no una copia en memoria:
const [fileHandle] = await window.showOpenFilePicker(); const file = await fileHandle.getFile(); const contents = await file.text();
Escribir de vuelta es igual de directo:
const writable = await fileHandle.createWritable(); await writable.write(updatedContents); await writable.close();
El soporte real a fecha de hoy sigue dividido. Chrome, Edge y Opera implementan la API completa, con selectores de archivo y directorio incluidos. Firefox y Safari solo ofrecen el Origin Private File System (OPFS), un sandbox privado por origen sin selectores que den acceso al disco real del usuario que en cambio es exactamente lo que necesitan motores como DuckDB-Wasm o wa-sqlite para persistir datos con rendimiento de I/O casi nativo mediante los sync access handles dentro de un Web Worker. Para herramientas que necesitan funcionar en todos los navegadores con acceso al disco real, el patrón habitual sigue siendo un Service Worker que empaqueta el resultado y lo entrega como descarga.
El Service Worker como proxy de red programable
La explicación habitual de los Service Workers se queda en el modo offline y las notificaciones push. Lo que se suele pasar por alto es que un Service Worker es, en esencia, un archivo JavaScript que se sitúa entre la aplicación y la red, intercepta cada petición y responde lo que se le indique.
Con él se puede servir contenido desde caché cuando no hay conexión, interceptar una llamada a la propia API y devolver datos sintéticos en pruebas, transformar una respuesta antes de que la vea la aplicación, o enrutar peticiones a backends distintos según condiciones definidas en el propio código cliente. El caso de testing es el que más ha calado entre equipos frontend: herramientas como Mock Service Worker (MSW) registran un Service Worker que intercepta URLs concretas y devuelve las respuestas que necesita cada test. La aplicación hace peticiones `fetch` reales, el Service Worker las captura y nada llega a la red, con una configuración notablemente más limpia que mockear a nivel de módulo o levantar un servidor de pruebas aparte.
Local-first: el servidor como destino de sincronización, no como fuente de la verdad
La pieza de datos es la que más ha madurado en los últimos dos años, hasta el punto de tener su propia vía dedicada en FOSDEM 2026. La convergencia de CRDTs (Automerge 3.0, Yjs), motores de sincronización basados en SQLite (cr-sqlite, PowerSync) y frameworks construidos específicamente para esto (Zero, de Rocicorp) ha dado a los equipos opciones de producción reales que hace tres años no existían.
Los distintos motores no son tres implementaciones de la misma idea: colocan la frontera de escritura en sitios distintos. Electric (tras su pivote en 2024 hacia un modelo «server-only» llamado Electric Next) resuelve solo la sincronización de lectura y deja todo el camino de escritura al desarrollador. PowerSync entrega una base de datos SQLite en el cliente junto con una cola de subida duradera, siempre que el endpoint de escritura sea síncrono con la base de datos origen. Cada elección implica un compromiso distinto entre simplicidad y control.
Para el caso de uso más sencillo una app que lee mucho y sincroniza de vez en cuando, como notas o paneles que deben seguir funcionando sin conexión ni siquiera hace falta un motor de sincronización dedicado. IndexedDB, con una capa como Dexie.js encima para no lidiar con su API nativa, ya cubre buena parte del terreno:
const db = new Dexie('miBaseDeDatos');
db.version(1).stores({ items: '++id, name, status' });
await db.items.add({ name: 'Tarea uno', status: 'pendiente' });
const pendientes = await db.items.where('status').equals('pendiente').toArray();
En todos estos patrones el servidor deja de ser la fuente única de la verdad y pasa a ser el destino de sincronización: los datos viven primero en el cliente y se propagan cuando hay conectividad, no al revés.
Lo que esto cambia en el diseño de arquitectura
Nada de esto implica que el backend sobre. Hay razones de peso para mantener el cómputo en el servidor: seguridad, datos que no pueden salir de la infraestructura de la empresa, o cargas que necesitan escalar más allá de lo que aguanta una pestaña. Pero buena parte del trabajo que hoy va al servidor lo hace por costumbre heredada de hace ocho o diez años, no por una necesidad técnica actual.
Los reflejos con los que muchos equipos siguen diseñando dan por hecho que procesar un archivo, ejecutar una búsqueda o guardar datos exige un servidor de por medio. A veces sigue siendo así. Pero con WASI 0.3 estabilizando el modelo de componentes, WebGPU cubriendo el cómputo paralelo, la File System Access API y OPFS dando acceso real a disco, y un ecosistema de sincronización local-first ya en producción, cada vez hay más casos en los que no lo es.
Antes de levantar un endpoint nuevo, vale la pena que cualquier equipo de desarrollo se haga hoy una pregunta que hace pocos años habría sonado fuera de lugar: ¿esto necesita de verdad un servidor?
Imagen: Unsplash / Growtika